home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1160 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.1 KB
  1. Date: Sat, 30 Jul 94 13:08 BST-1
  2. From: ogal@cix.compulink.co.uk (Ofir Gal)
  3. Subject: Re: app_defs.sys
  4. To: gem-list@world.std.com
  5. Message-Id: <memo.820730@cix.compulink.co.uk>
  6. Precedence: bulk
  7.  
  8.  
  9. In message <Pine.3.87.9407292201.A22510-0100000@grad>, millert@cs.csee.usf.edu said:
  10. >]
  11. >]Because there's an overwhelming majority saying the opposite?
  12. >
  13. >Do you know that for sure?  And why are they saying the opposite?
  14. >Because they haven't been plagued by this problem and they're too
  15. >short-sighted to see that a great many of other people HAVE.
  16.  
  17. We must be a bunch of extremely lucky people who have not been oplagued by
  18. this problem. There was a 97% majority against you last time I looked. And
  19. I don't think it's surprising. In fact, if there was a majority otherwise
  20. I would have unsubscribed as such a result would go totalloy against the
  21. idea of this mail list.
  22.  
  23. >Huh?  How will that help?  The whole problem is that GEM is too slow...
  24. >it has nothing to do with baud rates.
  25.  
  26. Try *reading* the HSModem docs.
  27.  
  28.  
  29. sjg@phlem.ph.kcl.ac.uk said:
  30. >
  31. >>   > KEYS
  32. >>   > *.*.*.*.*.*.
  33. >>   > etc...
  34. >>   >
  35. >> Not sure I like this, but that's quite possibly because I'm biased towards
  36. >> the .Xdefaults style. Given I can't come up with a concrete objection I guess
  37. >> you should just ignore me ;-)
  38. >
  39. >I'm not sure it's as flexible as the .Xdefaults way of doing things. What about
  40. >when you want to specify something for your app (eg: the corpse-offering that
  41. >Warwick does :-) that is outside the definitions ?
  42.  
  43. Then it should be in the Prefernce dialog of his program. It has no place
  44. in this file.
  45.  
  46. >At which point, writing individual app defaults files becomes easier as well.
  47. >You don't mess with the defaults file, but you're allowed to change your own.
  48. >Of course, the file format in both should be the same. I think X actually
  49. >has different file formats for the individual files, they are effectively
  50. >specified as having no <application> (first) field, and the name of the file
  51. >is prepended to all the entries. I can't actually see the point of this.
  52.  
  53. What do we need this for? Why can't apps just save their defaults to their
  54. own directories? Why create options that are just not needed? These ideas
  55. will create total chaos with 'normal' users. I find it interesting that
  56. these ideas come from people who use MiNT, Unix, etc. You are totally out
  57. of touch with the majority of ST users. You only need to man the Atari
  58. helpline once and you will realise how bad these ideas are.
  59.  
  60. I speak to hundreds of users through the Atari ST Review helpline - none of
  61. them uses MiNT, most do not even know what it is. A complex app-defs file
  62. like you are suggesting is a recipe for dissaster for these users.
  63.  
  64. I will personally not vote for any file format that goes beyond reassigning
  65. keyboard shortcuts AT THIS STAGE.
  66.  
  67.  
  68. mforget@elfhaven.ersys.edmonton.ab.ca said:
  69. >
  70. >Why not both?  It would only take a few extra minutes to write
  71. >pseudo-code.
  72.  
  73. Fine with me.
  74.  
  75. >On this point I disagree.  Per-application is vital, for exactly the
  76. >reason that was mentioned.  If you want a feature in one program, but
  77. >not in another, you need it.  If you want keypresses for unique
  78. >options in a program, you need per-application configuration.
  79. >
  80. >>I hope you are wrong. I don't think any app should write to the file, only
  81. >>read.
  82. >
  83. >Yes, the APP_DEFS.SYS file should be read-only for applications.  (Except
  84. >the editor that creates it, of course...)
  85.  
  86. And how will the editor know about the exisitance of app specific keys and
  87. options?
  88.  
  89. >>Why not save them the same way they are displayed in the menu? ^Q, etc.
  90. >
  91. >Only printable characters should be used in the file.  I am not sure if
  92.  
  93. Why? I have no intention of printing the file! It will make it much
  94. simpler to parse the file if it contains the same characters that are
  95. shown in the menu items.
  96.  
  97. >you can't type those characters easily in most editors.  Much better to
  98.  
  99. That is why we are going to have a GEM util to edit the config file. At
  100. any rate, press ALT+ASCII code to enter any ascii char you want.
  101.  
  102. Bye,
  103.  
  104. -----------------------------------------------------------------
  105. Ofir                                    ogal@cix.compulink.co.uk
  106. -----------------------------------------------------------------
  107.  
  108.